home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 1.6 KB | 38 lines | [TEXT/GEOL] |
- Item 6612282 26-Oct-90 14:33PDT
-
- From: JEFFRIES.L Leslie Jeffries,GEIS
-
- To: MACAPP.TECH$ MacApp Technical
-
- Sub: RE>UGridView
-
- Royston,
-
- I was a little dismayed by your evaluation of UGridView. The power of the unit
- is that the data can come from anywhere! A database, over the network,
- whatever! I don't know about your particular application, but a grid of
- in-memory objects isn't even feasible if your grid is very large. (Large of
- course depends on how big each of your objects are?)
-
- >> To quote, "the UGridView module is to provide the view that goes 'on top' of
- >> a list or grid framework. UGridView knows nothing about the underlying cell
- >> contents...".
-
- If you like the Model-View-Controller style of OOD, (which I do) then TGridView
- is just what you need. The data or cell contents in your application, the model
- part, can be completely independant of your view of that data. You can add more
- views of the same data without that data model changing. If a TGridView knew
- too much about its data contents, everytime you made a new view of the same
- data, you'd have to either duplicate the data objects stored for each cell (not
- very feasible), or connect up the new cells to the objects for a cell in
- another grid. It may be an advantage in your design to bind the cell contents
- with the view of the data. If so, then maybe you could come up with a useful,
- reuseable class that others could benefit from. But I, for one, wouldn't want
- MacApp to make any assumptions about the contents of a cell.
-
- Let's leave UGridView alone!
-
- Leslie Jeffries
- GE Information Services
-
-